Many electronic businesses, such as E-Commerce and other Internet based companies, rely heavily on Internet technology. As these companies grow, they seek to expand their capacities while preserving substantial investments they may have already made in computer hardware and software. Ultimately, these companies want to provide reliable services under heavy loads.
One approach to providing powerful and reliable services is associated with large multiprocessor systems (e.g., mainframes). Since more than one processor may be involved within a large system, services can continue even if one of a plurality of processors fail. These large systems, however, can be extraordinarily expensive.
Another approach to providing high volume services involves a plurality of less expensive systems (e.g., off the shelf PCs) configured as an array or cluster to support the load. Processing requests are distributed among the members of the cluster. Clusters provide an economical hardware solution, but can present operational issues that are not usually encountered in large dedicated systems.
One such issue is dealing with process state. Process state results when a subsequent processing request builds on an earlier processing request. For example, a first processing request may have resulted in data, such as shopping cart contents, being generated. If this data is stored in a local storage media associated with an individual member of the cluster and the subsequent processing request is routed to another member of the cluster, which can happen, for example, due to efforts at balancing load among cluster members, the data will not be available to the cluster member receiving the subsequent request.
One way to deal with this issue is to build stateless applications. Stateless applications have no state and can treat each processing request as though it comes from a separate and distinct user. This approach works well in some cases, but many services do not lend themselves to implementation with stateless applications.
Another approach is to maintain session state on the client. For example the state information can be transmitted to the client in an HTTP cookie generated by the server receiving the first processing request. The client makes the cookie available to the server that receives the subsequent processing request. This approach also has its uses, but has limitations related to security and the amount of state data that can be stored in this manner.
A further approach employs software to redirect processing requests. The environment for this software is typically a cluster of web servers sharing a logical Internet address. When a cluster member receives a request for processing that involves state, the client is provided with the IP address of an individual cluster member and directed to resubmit the request to that cluster member. This approach requires all the applications on the cluster that present links to use relative addressing and avoid having the client use the host name a second time over the course of the session. With this approach, state is usually lost once the connection with the client is broken. Another consequence is that the client may end up book-marking an individual cluster member's address, rather than the cluster address. If the individual member is unavailable when the client returns, the client will get an error such as “Host not found” rather than being routed to another cluster member.
A further approach employs hardware that routes all requests directed to the cluster. Commercially available routers, support what are called “sticky” connections, whereby requests from a specific client are routed to the same server if they arrive within a certain period of time, 5 minutes for example. Because such routers must handle large volume of traffic, they are generally expensive. They also create a point of weakness for a cluster in that if the router goes down, the entire cluster becomes unavailable. When intervals of “stickiness” are limited, state can still be lost if the session lasts beyond the stickiness interval.
Yet another approach is to maintain session state on a database to which all of the servers have access. Cookies, stored by the clients, can be used to identify the required session state and retrieve it from the database. This solution is also effective in many circumstances, but presents its own host of issues. The shared database requires additional hardware that can be expensive to buy and maintain, and load balancing can become an issue when the database is being accessed by a large number of servers.
Thus, in spite of a variety of attempts, there remains an unsatisfied need for an inexpensive, flexible, and reliable system for handling session state in a clusters of servers.